原先我對TDD並沒有太多的了解。原因之一，這是Aglie（敏捷開發）方法論的一環，而目前我所經歷的專案與團隊並沒有使用敏捷開發；之二，對於TDD，我一直以為就等於是Unit Testing，只是把寫Unit Testing Code的時間從寫程式本文後提前至寫程式本文前，就這麼簡單。事實上不然，TDD不單單指的是Unit Testing，事實上也可以用來進行後端的模組測試、整合測試等等。但TDD強調的不是＂測試＂這件事情，而是＂開發＂這件事情。為了要做好開發，所以先寫好測試程式，這對於某些想改變軟體品質的主管或是專案經理來說，看起來好像是個不小的誘惑，但真的做起來，這那麼簡單嗎？
最近幾天看了一些講TDD觀念與執行心得的文章，歸納了幾個想法，順便整理一下跟大家分享：

一、要導入TDD，軟體的需求必須明確，才有辦法讓測試程式碼開發先行，事實上Agile開發方法論強調的是應變需求的速度加快，但無法應付變化頻率太高或是變化幅度太大的軟體需求（以Scrum來說，一個衝刺周期建議是一個月，當然還是要看個別專案而定，但原則上不會偏離太大）。測試就是在測程式的＂功能＂，這可能小到是一支程式裡面的其中一個Function，抑或是大到系統中使用者會使用到的所有功能，若是軟體需求一直變更，變更幅度又非常大，連開發原來功能都來不及了，怎麼還會有時間來修改測試程式碼呢？

二、網路上看到有人說使用TDD，軟體開發的時間被拉長為原來的1.5~1.8倍，聽起來主管及PM的心臟要夠強，尤其在初期導入TDD的時候，往往會因為專案時程的壓力，把TDD三定律先拋在腦後，那TDD的導入註定要失敗。

（TDD三定律：(1)沒有測試之前不要寫任何功能代碼；(2)只編寫恰好能夠體現一個失敗情況的測試代碼；(3)只編寫恰好能通過測試的功能代碼）

三、在軟體開發工作中，我們常常會碰到，卻很少在文章討論中提到的，是所謂＂工作交接＂的問題。開發人員來來去去，人員異動，調動專案配合人員，常常在發生，一個交接不好，往往就變成了＂歷史的懸案＂，功能原來是好的，某天突然不能用，維護的工程師搞不清楚動了哪裡變成這樣。如果TDD有落實，可以避免類似的情形發生。當然，前提是要有落實。

四、TDD代表的另一層含義，叫做＂自動化測試＂。這又是一塊誘人的大餅，的確可以軟體開發在測試的成本上面大大地降低。不過，TDD本質上是屬於白箱測試，一般站在軟體品保的立場，還是會建議進行黑箱測試來找出原本未預期的問題。尤其當需要進行使用者介面的測試，如GUI，Web-Based操作等等系統測試，就不合適以TDD的方式來進行。就如同我前面所說的，TDD主要目的是協助開發，而非協助測試。

五、有人說施行了TDD，測試人員就不需要了，我倒不這麼認為，理由有下列三點：
1.測試人員在專案組織中多半也負責了軟體品保的其他工作，追蹤Defect/Issue處理進度，收集、協調、討論溝通問題，同時扮演第三方的角色來客觀監督審查專案的品質，甚至還可以幫忙PM檢查開發人員是否有落實TDD三定律，這部分是開發人員無法取代的。

2.對於測試的設計（Test Design），如Test Cases情境的撰寫，測試環境的準備與使用，測試人員還是比開發人員會多一些經驗與關注。簡單講一點，像＂等價分割法＂對於Test Cases的設計有效度是有幫助的，但這是測試方法論，不是開發方法論。太過於要求開發人員執行TDD的時候要懂得Test Cases Design，反而會分散了開發人員的專注力。

3.TDD是功能測試，非功能測試的部分（如安全性測試、效能測試等等）是TDD無法取代的，還是要有人進行這些測試。

看完TDD的一些討論，我越來越覺得，當整體組織的觀念尚未到位的時候，要推動一些新的軟體開發或是品保的方法論，是非常痛苦，而且是不容易成功的事情。即使觀念到位了，同時還要其他的條件配合（例如客戶，專案時程等）。有人說可以不要全面推動敏捷開發，只推TDD，我則認為這樣失敗的機率很高。